ГОСТ Р МЭК 61513-2011: Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования


ГОСТ Р МЭК 61513-2011: Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования

Терминология ГОСТ Р МЭК 61513-2011: Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования оригинал документа:

[МАГАТЭ 50-SG-D8]

Примечание 1 - См. также «система, важная для безопасности», «класс систем контроля и управления».

Примечание 2 - Система безопасности по МАГАТЭ соответствует в основном классу 1 данного стандарта.

Определения термина из разных документов: [МАГАТЭ 50-SG-D8]

3.40 анализ безопасности AC (plant safety analysis): См. А.2 приложения А.

Определения термина из разных документов: анализ безопасности AC

3.31 архитектура контроля и управления (l&C architecture): Организованная структура систем контроля и управления АС, которые являются важными для безопасности.

Примечание 1 - См. также «структура системы контроля и управления», «система контроля и управления».

Примечание 2 - Организованная структура определяет основные функции, класс и границы каждой системы, взаимосвязи и независимость систем, приоритетность и голосование между одновременно действующими сигналами и взаимодействие человек - машина.

Примечание 3 - В настоящем стандарте данный термин определяет только часть всей системы контроля и управления АС. Системы контроля и управления АС включают в себя также неклассифицированные системы и оборудование.

Определения термина из разных документов: архитектура контроля и управления

3.36 архитектура системы контроля и управления (l&C system architecture): Организованная структура системы контроля и управления.

Примечание - См. также «архитектура контроля и управления».

Определения термина из разных документов: архитектура системы контроля и управления

3.3 библиотека прикладных программ (application software library): Собрание программных модулей, предназначенных для выполнения типовых прикладных функций (см. рисунок 2).

Примечание - При использовании существующего оборудования такая библиотека рассматривается как часть системного программного обеспечения и квалифицируется соответствующим образом.

Определения термина из разных документов: библиотека прикладных программ

3.43 вероятностный метод (probabilistic method): См. А.2.2 приложения А.

Определения термина из разных документов: вероятностный метод

3.13 данные (data): Представление информации или сообщений в виде, подходящем для передачи, интерпретации или обработки с помощью компьютеров (см. рисунок 2).

[IEEE 610, модифицировано] [1]

Определения термина из разных документов: данные

3.15 детерминистический метод (deterministic method): См. А.2.2 приложения А.

Определения термина из разных документов: детерминистический метод

3.22 дефект (fault): Дефект в аппаратуре, программном обеспечении или в компоненте системы (см. рисунок 3).

Примечание 1 -Дефекты могут быть результатом случайных отказов, которые возникают, например, из-за деградации аппаратуры в результате старения; возможны систематические дефекты, например, в результате дефектов в программном обеспечении, возникающих из-за ошибок при проектировании.

Примечание 2 - Дефект (особенно дефекты, связанные с проектированием) может оставаться незамеченным, пока сохраняются условия, при которых он не отражается на выполнении функции, т.е. пока не произойдет отказ.

Примечание 3 - См. также «дефект программного обеспечения».

Определения термина из разных документов: дефект

3.58 дефект программного обеспечения (software fault): Ошибка программирования, содержащаяся в одном из компонентов программного обеспечения.

Примечание - См. также «дефект» (3.22).

Определения термина из разных документов: дефект программного обеспечения

3.55 единичный отказ (single failure): Случайный отказ, который выражается в потере способности компонента или системы выполнять предписанные функции. Отказы, возникающие как следствие единичного случайного события, рассматриваются как составляющие единичного отказа.

[МАГАТЭ 50-SG-D8, модифицировано]

Примечание 1 - См. также «критерий единичного отказа».

Примечание 2 - Единичный отказ может быть следствием как внутреннего, так и внешнего опасного воздействия.

Определения термина из разных документов: единичный отказ

3.63 жизненный цикл безопасности системы (system safety life cycle): Необходимая деятельность в отношении системы контроля и управления, важной для безопасности, которая осуществляется в течение периода времени от стадии развития концепции с разработкой требований до последней стадии, когда система больше не может эксплуатироваться.

Примечание 1 - Жизненный цикл безопасности системы связан с общим жизненным циклом безопасности.

Примечание 2 - См. также «общий жизненный цикл безопасности контроля и управления».

Определения термина из разных документов: жизненный цикл безопасности системы

3.54 защищенность (security): Способность компьютерной системы защитить информацию и данные так, чтобы не допустить их несанкционированного прочтения или изменения другими системами и отдельными лицами, и для того, чтобы допущенные к ним системы и лица не получали отказов.

[ИСО/МЭК12207, пункт 3.25, модифицировано]

Определения термина из разных документов: защищенность

3.5 канал (channel): Ряд взаимосвязанных компонентов внутри системы, которые формируют один выходной сигнал. Канал теряет свою индивидуальность, если его выходные сигналы сочетаются с сигналами от другого канала, например, канала контроля или канала безопасности.

Определения термина из разных документов: канал

3.4 категория функции контроля и управления (category of an l&C function): Одно из трех возможных обозначений (А, В, С) функций контроля и управления, устанавливаемое в результате рассмотрения влияния выполняемой функции на безопасность. Если функция не связана с безопасностью, то она не классифицируется.

Примечание 1 - См. также «класс системы контроля и управления», «функция контроля и управления».

Примечание 2 - Категории функций, систем и оборудования определены в МЭК 61226. Каждой категории соответствует ряд требований не только к функциям контроля и управления (связанных с их спецификацией, проектированием, внедрением, верификацией и валидацией), но и ко всей цепочке элементов, необходимых для реализации этой функции (связанной с характеристиками и соответствующей квалификацией) независимо от того, как они распределены между взаимосвязанными системами контроля и управления. Для большей ясности настоящий стандарт определяет категории функций контроля и управления и классы систем контроля и управления и устанавливает соотношение между категорией функции и минимальным требуемым классом соответствующих систем и оборудования.

Определения термина из разных документов: категория функции контроля и управления

3.46 качество (quality): Совокупность характеристик объекта, которые придают ему способность удовлетворить установленные и реализуемые требования.

[ИСО 8402, пункт 2.1]

Определения термина из разных документов: качество

3.45 квалификация (qualification): Процесс определения соответствия системы или компонентов эксплуатационным условиям. Квалификация осуществляется для установления соответствия определенного класса системы контроля и управления определенному набору квалификационных требований.

Определения термина из разных документов: квалификация

3.6 класс системы контроля и управления (class of an l&C system): Одно из трех возможных обозначений (1; 2; 3) систем, важных для безопасности, установленное в результате рассмотрения требований, предъявляемых к выполнению функций контроля и управления, имеющих разное отношение к безопасности. Если система контроля и управления не выполняет функции, связанные с безопасностью, то ее не классифицируют.

Примечание - См. также «категории функций, важных для безопасности», «элементы, важные для безопасности», «системы безопасности».

Определения термина из разных документов: класс системы контроля и управления

3.52 комплекс безопасности (safety group): Взаимосвязанный набор оборудования, спроектированный для выполнения всех операций, необходимых для того, чтобы гарантировать непревышение пределов, установленных проектом для данного постулированного исходного события.

Примечание - Функции контроля и управления в комплексе безопасности могут относиться к различным категориям.

Определения термина из разных документов: комплекс безопасности

3.18 комплекс оборудования (equipment family): Набор приборных и программных компонентов, которые могут работать совместно в одной или более определенных структурах (конфигурациях). Разработка специальной конфигурации для АС и соответствующего прикладного программного обеспечения может поддерживаться программными средствами. Комплекс оборудования обеспечивает набор стандартных операций (библиотеку прикладных функций), которые могут быть объединены, образуя специальное прикладное программное обеспечение.

Примечание 1 - См. также «функциональность», «прикладное программное обеспечение», «библиотека прикладных программ».

Примечание 2 - Линейка оборудования может быть как продуктом от определенного поставщика, так и набором изделий, соединение и адаптация которых выполнены поставщиком.

Примечание 3 - Иногда в качестве синонима термину «линейка оборудования» используют термин «приборная (аппаратная) платформа».

Определения термина из разных документов: комплекс оборудования

3.9 компонент (component): Одна из частей, из которых состоит система; компонент может представлять собой часть оборудования или программного обеспечения и может сам состоять из других компонентов.

[IEEE 610] [1]

Примечание 1 - См. также «система контроля и управления», «оборудование».

Примечание 2 - Термины «оборудование», «компонента» и «модуль» часто используют как взаимозаменяемые. Отношение между этими терминами пока не стандартизовано.

Определения термина из разных документов: компонент

3.10 компьютерная система (computer-based system): Система контроля и управления, функции которой в большой степени зависят или полностью выполняются с использованием микропроцессоров, программируемого электронного оборудования или компьютеров (см. рисунок 2).

Примечание - См. также «система контроля и управления».

Определения термина из разных документов: компьютерная система

3.14 концепция глубокоэшелонированной защиты (defence-in-depth concept): (см. А.3 приложения А).

Определения термина из разных документов: концепция глубокоэшелонированной защиты

3.56 критерий единичного отказа (single-failure criterion): Комплекс оборудования, отвечающий критерию единичного отказа, когда он способен функционировать в соответствии со своим предназначением, несмотря на допускаемый единичный случайный отказ, происшедший внутри комплекса. Последующие отказы, возникающие в результате допускаемого единичного отказа, рассматриваются как составляющие единичного отказа.

[МАГАТЭ 50-S-D]

Примечание 1 - См. также «единичный отказ», «отказ программного обеспечения».

Примечание 2 - Отказ из-за программного обеспечения является систематическим, а не случайным отказом.

Определения термина из разных документов: критерий единичного отказа

3.50 надежность (reliability): Вероятность того, что прибор, система или устройство будут выполнять назначенные функции удовлетворительно в течение определенного времени в определенных условиях эксплуатации.

[МАГАТЭ 50-SG-D8]

Примечание - Надежность компьютерных систем включает в себя как надежность технических средств, которая обычно выражается количественно, так и надежность программного обеспечения, которая обычно является качественной мерой, поскольку в большинстве случаев не существует критериев для установления числового значения его надежности.

Определения термина из разных документов: надежность

3.59 надежность программного обеспечения (software reliability): Составляющая надежности системы, которая зависит от отказов программного обеспечения.

Определения термина из разных документов: надежность программного обеспечения

3.29 независимое оборудование (independent equipment): Оборудование, которое обладает двумя следующими характеристиками:

a) способность выполнения функции не зависит от работы или отказа другого оборудования;

b) способность выполнения функции не зависит от воздействий, возникающих от постулированного исходного события, при котором требуется ее выполнение.

[МАГАТЭ 50-SG-D8]

Примечание - При проектировании средствами достижения независимости являются изоляция (в документах МАГАТЭ употребляется также термин «функциональная изоляция»), физическое разделение и коммуникационная независимость.

Определения термина из разных документов: независимое оборудование

3.47 обеспечение качества (quality assurance): Совокупность планируемых и систематически проводимых мероприятий, необходимых для создания уверенности в том, что продукция или услуга будет соответствовать определенным требованиям к качеству.

[ИСО 8402, пункт 3.5, модифицировано]

Определения термина из разных документов: обеспечение качества

3.17 оборудование (equipment): Одна или более частей системы. Элемент оборудования - отдельная (обычно заменяемая) часть системы.

[МЭК 61226, модифицировано]

Примечание 1 - См. также «компонент», «система контроля и управления».

Примечание 2 - Оборудование может включать в себя программное обеспечение.

Примечание 3 - Термины «оборудование», «компонент» и «модуль» часто применяют как синонимы. Отношение между ними пока не стандартизованы.

Определения термина из разных документов: оборудование

3.27 опасность (hazard): Событие, способное причинить вред здоровью персонала АС, привести к повреждению узлов, оборудования или строительных конструкций. Опасности подразделяются на внутренние и внешние.

Примечание 1 - Внутренние опасности представляют собой, например, пожар и затопление. Внутренние опасности могут являться последствиями постулированных исходных событий.

Примечание 2 - Примером внешних опасностей может служить землетрясение или удар молнии.

Определения термина из разных документов: опасность

3.21 отказ (failure): Отклонение реального функционирования от запланированного (см. рисунок 3). [МЭК 60880-2, пункт 3.8]

Примечание 1 - Отказ является результатом сбоя в аппаратуре, программном обеспечении, системе или ошибки оператора или обслуживания и отражается на прохождении сигнала.

Примечание 2 - См. также «дефект», «отказ программного обеспечения».

Определения термина из разных документов: отказ

3.7 отказ по общей причине (ОПП) (common cause failure - CCF): Отказ, явившийся результатом одного или более событий, вызывающих одновременный отказ двух или более отдельных каналов многоканальной системы или многоканальных систем и приводящий к отказу системы (систем).

[МЭК61508-4 пунктЗ.6.10, модифицировано]

Примечание - В зависимости от контекста отказ по общей причине может рассматриваться на уровне системы или на уровне нескольких систем, образующих комплекс безопасности.

Определения термина из разных документов: отказ по общей причине (ОПП)

3.57 отказ программного обеспечения (software failure): Отказ системы из-за проявившейся проектной ошибки в компоненте программного обеспечения

Примечание 1 - Все отказы программного обеспечения связаны с ошибками при проектировании, так как программное обеспечение в данном контексте не связано с физическими носителями, не изнашивается или не страдает от физических отказов. Так как триггеры, которые являются источниками сбоев программного обеспечения, задействуются при работе системы случайным образом, то отказы программного обеспечения имеют также случайный характер.

Примечание 2 - См. также «отказ», «сбой», «сбой программного обеспечения».

Определения термина из разных документов: отказ программного обеспечения

3.20 оценка (свойства системы) (evaluation of a system property): Приписывание качественного или количественного значения данному свойству системы.

[МЭК 61069-1, пункт 2.2.2]

Определения термина из разных документов: оценка

3.28 ошибка персонала (human error or mistake): Отдельное действие персонала или процедура, которые приводят к непредвиденному результату.

Определения термина из разных документов: ошибка персонала

3.51 повторно используемое программное обеспечение (reusable software): Программный модуль, который может использоваться более чем в одной компьютерной программе или программном обеспечении системы.

[IEEE 610, модифицировано] [1]

Определения термина из разных документов: повторно используемое программное обеспечение

3.19 погрешность (error): Расхождение между рассчитанным, наблюдаемым или измеренным значениями величины или условиями и истинным, установленным или теоретическим значениями величины или условий (см. рисунок 3).

Определения термина из разных документов: погрешность

3.33 подфункция контроля и управления (l&C subfunction): Часть функции контроля и управления, заложенной в систему контроля и управления или в подсистему.

Примечание 1 - См. также «функция контроля и управления» и «прикладная функция».

Примечание 2 - Вместо термина «подфункция» часто употребляется термин «функция», если в контексте не возникает двусмысленности.

Определения термина из разных документов: подфункция контроля и управления

3.39 полный жизненный цикл безопасности контроля и управления (overall safety life cycle of the l&C): Необходимый объем действий, включающий в себя оснащение всей архитектуры контроля и управления системами и оборудованием, важными для безопасности, и выполняемый в течение периода времени, начиная с установления требований на основе проекта безопасности АС, и заканчивая периодом, когда ни одна система контроля и управления не пригодна к эксплуатации.

[МЭК 61508-4, пункт 3.7.1, модифицировано]

Определения термина из разных документов: полный жизненный цикл безопасности контроля и управления

3.41 постулированное исходное событие (postulated initiating event - PIE): Постулированные исходные события, определяющие события, которые приводят к определенным нарушениям эксплуатации или аварийным условиям с последующими отказами оборудования.

[МАГАТЭ 50-C-D]

Примечание 1 - Ожидаемые эксплуатационные происшествия: все эксплуатационные процессы, имеющие отклонения от нормальной эксплуатации, которые происходят один или несколько раз в течение времени эксплуатации АС и ввиду предусмотренных проектом мер не вызывают каких-либо значительных повреждений объектов, важных для безопасности, и не приводят к аварийным условиям.

Примечание 2 - Первичными причинами постулированных исходных событий могут быть вероятные отказы оборудования и ошибки персонала (как на самой АС, так и вне ее), события, вызванные воздействием человеческого фактора или природных явлений. Перечень постулированных исходных событий должен быть установлен надзорным органом.

Определения термина из разных документов: постулированное исходное событие

3.30 прерывание (interrupt): Приостановление процесса, например, выполнения компьютерной программы, вызванное внешним по отношению к данной программе событием.

[IEEE 610]

Определения термина из разных документов: прерывание

3.11 приемка на AC (commissioning of the NPP): Процесс, при котором собранные компоненты и системы вводятся в действие, верифицируются (подвергаются испытаниям) на соответствие техническим требованиям и характеристикам назначения; они могут включать в себя испытания как с применением радиоактивных и ядерных материалов и излучений, так и без них.

[МАГАТЭ 50-S-D]

Определения термина из разных документов: приемка на

3.1 прикладная функция (application function): Функция системы контроля и управления по выполнению задачи, связанной с контролируемым процессом, а не с функционированием самой системы.

[МЭК 60880, пункт 2.1, модифицировано]

Примечание 1 - См. также «функция контроля и управления», «система контроля и управления», «прикладное программное обеспечение».

Примечание 2 - Прикладная функция является обычно одной из функций контроля и управления.

Определения термина из разных документов: прикладная функция

3.2 прикладное программное обеспечение (application software): Часть программного обеспечения системы контроля и управления, которое обеспечивает выполнение прикладных функций (см. рисунок 2).

Примечание 1 - См. также «прикладная функция», «библиотека прикладных программ», «системное программное обеспечение системы».

Примечание 2 - Прикладное программное обеспечение отличается от системного.

Определения термина из разных документов: прикладное программное обеспечение

3.48 программа качества (quality plan): Документ, регламентирующий конкретные меры в области качества, распределение ресурсов и последовательность действий, относящихся к конкретной продукции, услуге, контракту или проекту.

Определения термина из разных документов: программа качества

5.3.1 Проект архитектуры контроля и управления

Проект архитектуры контроля и управления определяет верхний уровень систем контроля и управления АС (см. раздел В.4 приложения В), связи между этими системами и средства обеспечения согласованного интерфейса между этими системами.

5.3.1.1 Основные требования

a) Проект архитектуры контроля и управления должен охватывать все аспекты контроля и управления с тем, чтобы выделить функции контроля и управления, важные для безопасности, приведенные в 5.2.

b) Проект должен распределять контроль и управление по достаточному числу систем и оборудования, чтобы соответствовать требованиям к:

- независимости функций в различных эшелонах защиты;

- соответствующему разделению систем по классам;

- выполнению требований к физическому разделению и электрической изоляции в соответствии с ограничениями, вытекающими из условий внешней среды и расположения АС, анализа опасностей, а также связанными с обслуживанием при эксплуатации (см. 5.3.1).

c) Проект архитектуры должен предусматривать достаточное число систем и подсистем, чтобы принцип единичного отказа выполнялся для функций категории А во всех допустимых конфигурациях систем и АС (см. 7.5 МАГАТЭ 50-SG-D3).

d) Каждая система контроля и управления должна быть классифицирована в соответствии с ее назначением в системе функций контроля и управления согласно установленной категории (см. таблицу 2).

e) Интерфейс с оборудованием АС и взаимосвязи между системами контроля и управления должны определяться в составе проекта архитектуры для того, чтобы установить:

- распределение сигналов (измерений) по различным функциям, важным для безопасности;

- выбор и приоритетность исполнительных сигналов различных систем;

- пути прохождения сигналов и оборудование, общее для выполнения автоматических функций или ручного управления на различных уровнях глубокоэшелонированной защиты.

f) Описание систем, оборудования и их взаимодействия в проекте архитектуры контроля и управления должно быть достаточно подробным, чтобы способствовать анализу вопросов безопасности контроля и управления.

Таблица 2 - Соотношение между классами систем контроля и управления и категориями ФСО

Категории функций контроля и управления, важных для безопасности

Соответствующий класс систем контроля и управления, важных для безопасности

А

(В)

(С)

1

В

(С)

2

C

3

Примечание - Функции категории А могут выполняться только системами класса 1; функции категории В - системами классов 1 и 2; функции категории С - системами классов 1, 2 и 3.

5.3.1.2 Интерфейсы человек - машина

a) Проект архитектуры контроля и управления должен распределять системы с интерфейсом человек- машина по различным помещениям АС, предназначенным для управления и наблюдения, включая блочный пункт управления (далее - БПУ) и дополнительные помещения, резервный щит управления (см. МЭК 60965), местные щиты управления и пункт управления противоаварийными действиями, с необходимой степенью резервирования, с учетом ограничений, накладываемых эксплуатацией и обслуживанием оборудования АС (см. 5.1.1).

b) Проект должен опираться на принципы эксплуатации, установленные в проекте АС (см. 5.1.1), включая:

- принципы приоритетности между автоматическими сигналами и сигналами управления, вводимыми вручную;

- принципы приоритетности между различными системами взаимодействия человеко-машинных интерфейсов при нормальной эксплуатации, аварии и эксплуатации после аварии;

- принципы приоритетности между основными и резервными человеко-машинными интерфейсами;

- принципы переключения основных и резервных человеко-машинных интерфейсов.

c) Проект архитектуры должен определять, как оператор получит извещения о сбоях и отказах, регистрируемых средствами диагностики отдельных систем. Форма представления должна быть такой, чтобы оператор имел возможность:

- немедленно по индикации опознать отказ и отличать его от других индицируемых эксплуатационных данных;

- решить, не следует ли применить ручное управление для перевода АС в безопасное состояние;

- определить системы, которые следует восстановить с помощью обслуживающего персонала.

d) Проект архитектуры контроля и управления должен соответствовать основным решениям по технологии систем человеко-машинного интерфейса (например, компьютеризированная или традиционная). Для представления информации операторам должны использоваться более сложные системы, если это снижает влияние человека на возникновение отказа и это влияние можно сократить благодаря получению более качественной информации. Уровень отказов компьютерных информационных систем вследствие отказов по общей причине следует рассматривать в сравнении с уровнем отказов вследствие влияния человеческого фактора.

e) В проекте:

- должны быть указаны функции, управляемые человеком и управляемые автоматически в соответствии с анализом задач, выполненным в проекте АС (см. 5.1.1);

- должна быть определена способность системы контроля и управления осуществлять необходимую обработку информации и завершать задачи, определенные в результате взаимодействия с оператором (см. 3.2.2 МЭК 60964);

- должно быть обеспечено соответствие информации и времени, имеющихся у оператора для выполнения управления вручную, требованиям проекта АС (см. 5.1.1).

f) Для обеспечения эффективности взаимодействия человек - машина в проекте БЩУ и других щитовых помещений АС должны использоваться технические средства, основанные на требованиях МЭК 60964 и МЭК 60965.

g) При анализе проекта должны рассматриваться задачи оператора и оптимизация требований к взаимодействию человек - машина при выполнении как важных для безопасности, так и не влияющих на безопасность задач.

5.3.1.3 Средства передачи данных

Средства передачи данных между системами, образующими архитектуру контроля и управления, включают в себя все линии, обеспечивающие прохождение одного или более сигналов или сообщений по одному или более пути с использованием различной мультиплексной техники.

a) Линии передачи данных должны соответствовать общей спецификации требований к рабочим характеристикам (см. 5.2) при всех условиях работы АС.

b) Архитектура и технология линий передачи данных должны обеспечивать соблюдение требований независимости систем. Кроме физического разделения и электрической изоляции в проекте должны быть предусмотрены меры, гарантирующие отсутствие влияния неполадок в системе передачи данных на работу средств обработки.

c) Линии передачи данных должны включать в себя средства проверки работоспособности коммуникационного оборудования и полноты передаваемых данных.

d) Для устойчивости к отказам должно быть обеспечено резервирование линий передачи данных.

е) Линии передачи данных должны быть спроектированы так, чтобы передача данных и выполнение функции более высокой категории безопасности не нарушались при передаче данных в системе более низкого класса. Например, выполнение тестов на работоспособность не должно мешать выполнению функции высшей категории.

5.3.1.4 Инструментальные средства

a) В проект архитектуры контроля и управления должны быть включены инструментальные средства, выполняемые обычно на базе компьютеров (см. 4.2 МЭК 60880-2), которые обеспечивали бы устойчивость обмена данными между системами контроля и управления, работающими совместно, и гарантировали бы сохранность базы данных АС.

Примечание - Специальные инструментальные средства для отдельных систем выбирают на стадии разработки спецификации системы (см. 6.1.3.2).

b) Инструментальные средства должны применяться на всех фазах полного жизненного цикла безопасности, за счет чего может быть достигнуто повышение качества и надежности функций, важных для безопасности, например, для поддержки:

- аспектов, связанных с проектом интерфейсов между системами контроля и управления;

- общей интеграции и приемки распределенных функций.

5.3.1.5 Защита от отказов по общей причине

Цель проекта архитектуры контроля и управления - обеспечить меры защиты от отказов по общей причине систем контроля и управления путем введения различных защитных мер против одних и тех же постулированных исходных событий (см. 5.1.1).

Эти меры защиты включают в себя:

- проектные решения по обеспечению устойчивости к опасным событиям на АС. Внешние и внутренние опасности (см. 5.1.3), влияние которых не исключено для ограниченной части архитектуры контроля и управления и которые могут привести к отказам по общей причине;

- проектные решения, направленные против отказов, которые могут быть вызваны изменениями в нагрузке АС. Включение некоторых компонентов оборудования, например, усилителей мощности и реле, или ввод компонентов программного обеспечения, например, таких как сбор входных данных, передача данных и переключение эксплуатационных режимов, могут зависеть от событий, происходящих на АС;

- проектные решения по минимизации использования общих ресурсов в архитектуре контроля и управления и взаимодействия человек- машина для различных уровней защиты. Такие общие ресурсы можно представить в виде использования одного сигнала измерения или обычной технологической операции в различных управляющих действиях;

- решения по минимизации риска систематических сбоев. В любой системе контроля и управления существует риск проектных ошибок или присутствуют ошибки, связанные с реализацией. Поэтому возможность сбоя программного обеспечения, вызывающего отказ, нельзя исключить при анализе любого отказа системы. Если используются одинаковые программные модули в сходных условиях в разных компьютерных системах, существует риск отказа по общей причине вследствие такой ошибки в программном обеспечении;

- использование разнообразия. Разнообразие обеспечивает несколько различных путей обнаружения значительных событий и реагирования на них для увеличения защиты от отказа по общей причине. К видам разнообразия относятся разнообразие персонала, разнообразие сигналов (использование разных измерительных параметров для инициирования защитных действий), функциональное разнообразие, разнообразие проектных решений и проверок, разнообразие программного обеспечения и оборудования;

- принятие стратегических решений по ограничению сложности. Использование компьютеров способствует выполнению более сложных алгоритмов и процессов, чем это возможно с помощью оборудования с жесткой логикой. При более сложных требованиях возможность ошибок и просчетов в спецификации требований и ошибок в проекте и при реализации становится значительно больше, чем в случае простых требований.

5.3.1.5.1 Устойчивость к внутренним и внешним воздействиям, которые могут привести к отказу по общей причине

Необходимо принять меры, обеспечивающие работоспособность комплекса безопасности, выполняющего функции категории А, которые требуется поддерживать на случай противодействия внутренним и внешним опасным воздействиям.

Эти меры включают в себя:

- разделение, например, размещение резервных частей системы в различных помещениях;

- независимость, например, систем подогрева, вентиляции и кондиционирования воздуха и отдельных источников энергоснабжения для каналов и систем;

- защита, например, от огня, воздействия химических веществ и вибрации;

- проектирование, например, оборудования в соответствии со стандартами МЭК по электромагнитной совместимости;

- квалификацию по воздействиям окружающей среды, например, по отношению к сейсмическим воздействиям (см. 6.4).

5.3.1.5.2 Защита от отказов по общей причине вследствие изменения потребности в энергии

a) Необходимо определить выполняющие функции категории А компоненты систем контроля и управления, работа которых зависит от нагрузки станции. Возможные виды отказов и их последствия (включающие в себя их влияние на компоненты, работа которых не зависит от режима нагрузки станции) должны быть оценены с точки зрения вероятных источников и эффектов отказа по общей причине.

b) Риск отказов по общей причине систем класса 1 должен быть минимизирован за счет использования систем контроля и управления и обеспечивающих систем, которые работают в одном и том же режиме как до, в процессе, так и после изменения нагрузки, т.е. их работа не должна зависеть от графика приложения нагрузки.

5.3.1.5.3 Защита за счет проектных решений по архитектуре систем контроля и управления и человеко-машинному интерфейсу

a) Различные рубежи защиты против постулированных исходных событий должны быть оснащены независимыми системами или подсистемами (см. примечание 1 к 5.1.1). Если используются общие ресурсы, они должны соответствовать плану обеспечения надежности комплекса безопасности.

b) Должны быть предусмотрены независимые средства контроля и управления функциями и системами, важными для безопасности АС (например, мультиплексные линии передачи данных или компьютеры), чтобы во время отказа имелась достаточная информация, необходимая для безопасной эксплуатации АС.

c) Если управление функциями категории А или В выполняется вручную как дублирующее действия автоматики, то возможность отказа по общей причине в процессе этих действий должна быть сведена к минимуму.

d) Если одна функция категории А может инициировать действие системы безопасности, а другая функция категории А, применяемая при других обстоятельствах, может вызвать противоположное действие, необходимо провести анализ с целью определения того действия, которое требуется выполнить в условиях отказа систем контроля и управления.

5.3.1.5.4 Защита от отказа по общей причине вследствие систематических сбоев

a) Планирование высокого качества, предусмотренное при разработке и создании различных систем контроля и управления комплекса безопасности, должно исключать случаи невыявленных отказов и, таким образом, свести риск отказов этих систем по общей причине к минимуму. Настоящий стандарт содержит требования, которые следует применять для обеспечения качества систем контроля и управления различных классов.

b) Систематические отказы должны выявляться средствами самоконтроля (исключая использование ручек настройки, аппаратуры самоконтроля, проверок правдоподобия), а выявляемые отказы должны переводить систему(ы) в предварительно установленное, предпочтительно безотказное состояние, при этом оператор должен получать сообщение об отказе.

c) Если требуемая надежность безотказного выполнения функции безопасности больше, чем надежность, полученная в результате оценки безотказного состояния данной системы, то проект данной системы следует переработать.

Примечание 1 - Требуемая степень защиты от отказов зависит от категории выполняемых функций.

Примечание 2 - Цель настоящего подраздела - дать общие сведения. Детальные требования к защите от отказов по общей причине вследствие ошибок в программном обеспечении для функций категории А приведены в 4.1 МЭК 60880-2.

5.3.1.5.5 Защита за счет разнообразия

a) В случае, если требуется высокая надежность комплекса безопасности, при проектировании архитектуры контроля и управления следует опираться на принцип разнообразия, особенно если имеются неопределенности в выполненных в проекте оценках.

b) Необходимо рассмотреть методы функционального разнообразия и разнообразия сигнала. Эти методы являются эффективными для снижения вероятности отказа по общей причине, возникшего вследствие ошибок в спецификациях требований или в спецификации и установке прикладного программного обеспечения.

c) Разнообразие оборудования может быть эффективным против отказа по общей причине компонентов аппаратного обеспечения и может обеспечить защиту против сбоев программного обеспечения системы. В частности, ее следует рассматривать при создании сложных систем, если опыт эксплуатации подобных систем ограничен.

d) Следует использовать разнообразие процедур или методов верификации и валидации (например, разнообразие оборудования для электромагнитных испытаний, испытания на взаимную совместимость с использованием эмулятора и пр.), что дополнительно поможет избежать отказов по общей причине без усложнения системы защиты.

e) Если для защиты против отказа по общей причине используется защита за счет разнообразия, то в проект следует включить анализ ее эффективности. Как положительный, так и отрицательный результат следует зафиксировать и отразить в документации (см. 5.3.3).

5.3.1.5.6 Стратегические решения по ограничению сложности

Для того, чтобы снизить до минимума вероятность отказа по общей причине из-за сложности систем, проектирование архитектуры контроля и управления должно включать в себя анализ, показывающий, что степень применения компьютеров вместо систем, построенных на жесткой логике и степень участия человека приемлемы сточки зрения обеспечения безопасности.

Примечание - Такой подход может зависеть от национального опыта, позиции регулирующего органа и надежности компьютерных технологий.

Определения термина из разных документов: Проект архитектуры контроля

3.44 проектная организация (project organization): Организация(и) или лица, которые в процессе прохождения всех фаз общего жизненного цикла безопасности контроля и управления и/или системы контроля и управления несут ответственность за определение и осуществление всей организационной и технической деятельности, связанной с функциями контроля и управления, системами и оборудованием, важными для безопасности.

Примечание - Этот термин введен для более четкого отличия от термина «эксплуатирующая организация».

Определения термина из разных документов: проектная организация

3.16 разнообразие (diversity): Наличие двух или более путей или средств достижения установленной цели. Разнообразие специально создается как защита от отказа по общей причине. Оно может быть достигнуто наличием систем, которые физически отличаются одна от другой, или с помощью функционального разнообразия, если аналогичные системы достигают установленной цели различными путями.

[МЭК 60880-2, пункт 3.6]

Примечание 1 - См. также «функциональное разнообразие».

Примечание 2 - Это определение шире, чем использованное в МАГАТЭ 50-C-D: «существование избыточных компонентов или систем с целью выполнения определенной функции, когда такие компоненты или системы совместно несут в себе одну или более различных характеристик. Например, такие характеристики, как различные условия работы, размеры оборудования, производители, принципы функционирования и типы оборудования, использующие различные физические методы».

Определения термина из разных документов: разнообразие

3.42 ранее разработанное программное обеспечение (pre-developed software - PDS): Часть программного обеспечения, которая уже существует и доступна как коммерческий или запатентованный продукт.

[МЭК 60880-2, пункт 3.1]

Примечание - Ранее разработанное программное обеспечение можно разделить на: программное обеспечение общего назначения, которое не разрабатывалось для определенного оборудования, и программное обеспечение, интегрированное в компоненты оборудования, которое применяется совместно с оборудованием.

Определения термина из разных документов: ранее разработанное программное обеспечение

3.49 резервирование (redundancy): Способ обеспечения надежности объекта за счет использования дополнительных средств и/или возможностей, избыточных по отношению к минимально необходимым для выполнения требуемых функций.

[МАГАТЭ 50-SG-D8]

Определения термина из разных документов: резервирование

3.38 ремонтопригодность (maintainability): Вероятность того, что конкретная операция по обслуживанию устройства в данных условиях эксплуатации может быть выполнена в заранее определенный период времени, в заранее определенных условиях с использованием заранее определенных операций и средств.

[МЭК 60987, пункт 2.10, модифицировано]

Определения термина из разных документов: ремонтопригодность

3.61 система (system): Конфигурация взаимодействующих в соответствии с проектом составляющих, в которой элемент системы может сам представлять собой систему, называемую в этом случае подсистемой.

[МЭК 61508-4, пункт 3.3.1, модифицировано]

Примечание 1 - См. также «система контроля и управления».

Примечание 2 - Системы контроля и управления следует отличать от механических систем и электрических систем АС.

Определения термина из разных документов: система

3.35 система контроля и управления (СКУ) (l&C system): Система, основанная на применении электрической и/или электронной и/или программируемой электронной техники, выполняющая функции контроля и управления, а также функции обслуживания и наблюдения, связанные с эксплуатацией самой системы. Термин используется как обобщающий, охватывающий все элементы системы, включая питание, датчики и другие входные устройства, линии передачи данных и другие связи, интерфейсы исполнительных устройств и других выходных устройств (см. примечания). Различные функции системы могут использовать как выделенные, так и разделенные ресурсы.

[МЭК 61508-4, пункт 3.3.2, модифицировано]

Примечание 1 - См. также «система», «функция контроля и управления».

Примечание 2 - Элементы, входящие в состав определенной системы контроля и управления, определяют границы этой системы.

Примечание 3 - В соответствии с их функциональностью МАГАТЭ делает различие между системами автоматического и ручного управления, системами взаимодействия человек - машина, системами защиты и блокировки.

Определения термина из разных документов: система контроля и управления (СКУ)

3.62 систематический отказ (systematic failure): Отказ, обусловленный определенной причиной, который может быть исключен за счет внесения изменений в проект или в технологический процесс, эксплуатационную операцию, документацию и т.п.

[МЭК 61508-4, пункт 3.6.6]

Определения термина из разных документов: систематический отказ

3.64 системное программное обеспечение (system software): Программное обеспечение, спроектированное для определенной компьютерной системы или семейства компьютерных систем с целью эксплуатации и обслуживания компьютерной системы и установленных программ, например, операционные системы, ЭВМ, утилиты. Системное программное обеспечение обычно состоит из операционного системного программного обеспечения и инструментальных программ (см. рисунок 2).

[МЭК 60880-2, 3.24]

Примечание 1 - Операционное системное программное обеспечение: программы, загруженные в основной процессор в течение времени работы системы, такие как, операционная система, входные и выходные драйверы, коммуникационные программы, библиотеки прикладных программ, on-line диагностика, программы сжатия, упрощенные программы управления.

Примечание 2 - Инструментальные программы: программы, которые используют при разработке, тестировании или обслуживании других программ и систем, таких как компиляторы, генераторы кодов, графические редакторы, off-line диагностика, средства верификации и валидации.

Примечание 3 - См. также «прикладное программное обеспечение».

x004.jpg

Рисунок 2 - Характерные взаимосвязи между аппаратными и

x005.png

Рисунок 3 - Связь между отказом системы, случайным отказом и систематическим
дефектом

Определения термина из разных документов: системное программное обеспечение

3.53 системы безопасности (safety systems): Системы, обеспечивающие при требуемых условиях безопасный останов реактора и отвод тепла от активной зоны и/или ограничивающие последствия возможных эксплуатационных происшествий и аварийных условий.

Определения термина из разных документов: системы безопасности

3.8 сложность (complexity): Свойство системы или компонента, имеющих устройство, исполнение или поведение, трудные для понимания или верификации.

[IEEE 610, модифицировано] [1]

Определения термина из разных документов: сложность

3.60 спецификация (specification): Документ, определяющий в полной, точной, проверяемой форме требования, дизайн, поведение или другие свойства системы либо компонента, и, зачастую, процедуры, для определения, выполняются ли эти требования.

[МЭК 60880-2, 3.21 и IEEE 610] [1]

Определения термина из разных документов: спецификация

3.12 управление конфигурацией (configuration management): Порядок применения технической и административной директивы и контроля с целью определения и документирования функциональных и физических характеристик сложного устройства, управления изменением таких характеристик, ведения записей и отчетов об изменении в работе и настройке, а также проверки соответствия определенным требованиям.

[IEEE 610] [1]

Определения термина из разных документов: управление конфигурацией

3.34 функции и соответствующие системы и оборудование (functions, and the associated systems and equipment): Выполнение функции заключается в достижении определенной цели; соответствующие системы и оборудование представляют собой совокупность компонентов и компоненты сами по себе, которые используются для выполнения функции.

[МЭК 61226, модифицировано]

Примечание - См. также «функция контроля и управления», «система контроля и управления».

Определения термина из разных документов: функции и соответствующие системы и оборудование

3.24 функциональная валидация (functional validation): Проверка правильности применения спецификаций прикладных функций относительно исходных требований к функциям и эксплуатационным характеристикам станции. Функциональная валидация дополняет валидацию системы и оценивает ее соответствие спецификации функций.

Определения термина из разных документов: функциональная валидация

3.23 функциональное разнообразие (functional diversity): Применение разнообразия на функциональном уровне (например, при достижении предельных значений как давления, так и температуры).

[МЭК 61069-1, пункт 2.2.2]

Примечание - См. также «разнообразие».

Определения термина из разных документов: функциональное разнообразие

3.25 функциональность (functionality): Характеристика функции, которая определяет процедуры переработки входной информации в выходную информацию.

Примечание - Выполнение прикладных функций определяющим образом влияет на работу АС. Входная информация может поступать от датчиков, блоков обработки, другого оборудования или другого программного комплекса. Выходная информация может воздействовать на исполнительные механизмы, блоки обработки, другое оборудование и другое программное обеспечение (см. [4]).

Определения термина из разных документов: функциональность

3.32 функция контроля и управления (l&C function): Функция контроля, управления и/или наблюдения за определенной частью процесса.

Примечание 1 - См. также «подфункции контроля и управления», «функции контроля и управления и соответствующие системы и оборудование», «прикладные функции».

Примечание 2 -Данный термин применяется разработчиками процесса при определении требований к функционированию контроля и управления. Функция контроля и управления определяется так, что она:

- дает полное представление о цели выполнения функции,

- может быть классифицирована по степени важности для безопасности,

- охватывает все составляющие от датчика до исполнительного устройства для достижения цели.

Примечание 3 - Функция контроля и управления может быть разделена на ряд подфункций (например, измерительная функция, функция управления, функция воздействия) с целью распределения по системам контроля и управления.

Определения термина из разных документов: функция контроля и управления

3.26 функция, важная для безопасности (function important to safety): Особая цель, которая должна способствовать безопасности.

[МАГАТЭ 50-SG-D3 и МЭК 61226, модифицировано]

Примечание - См. также «функция контроля и управления», «подфункция контроля и управления», «прикладная функция».

Определения термина из разных документов: функция,

3.37 элементы, важные для безопасности (items important to safety): Элементы, которые включают в себя:

a) сооружения, системы и компоненты, неисправность или отказ которых могут привести к непредусмотренному облучению персонала АС или населения;

b) сооружения, системы и компоненты, которые препятствуют развитию возможных случаев нарушений нормальной эксплуатации при аварийной ситуации;

c) средства, обеспечивающие смягчение последствий неисправности или отказа сооружений, систем или компонентов.

[МАГАТЭ 50-SG-D3]

Примечание 1 - См. также «система безопасности», «класс системы контроля и управления».

Примечание 2 - В данном стандарте системы контроля и управления, важные для безопасности, подразделяются на три класса: 1; 2; 3.

Примечание 3 - IAEA 50-SG-D8 подразделяет системы, важные для безопасности, на «системы безопасности» и «системы, связанные с безопасностью».

Определения термина из разных документов: элементы, важные для безопасности

Словарь-справочник терминов нормативно-технической документации. . 2015.

Смотреть что такое "ГОСТ Р МЭК 61513-2011: Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования" в других словарях:

  • ГОСТ Р МЭК 61513-2011 — 82 с. (12) Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования раздел 27.120.20 …   Указатель национальных стандартов 2013

  • элементы, важные для безопасности — 3.37 элементы, важные для безопасности (items important to safety): Элементы, которые включают в себя: a) сооружения, системы и компоненты, неисправность или отказ которых могут привести к непредусмотренному облучению персонала АС или населения;… …   Словарь-справочник терминов нормативно-технической документации

  • класс системы контроля и управления — 3.6 класс системы контроля и управления (class of an l C system): Одно из трех возможных обозначений (1; 2; 3) систем, важных для безопасности, установленное в результате рассмотрения требований, предъявляемых к выполнению функций контроля и… …   Словарь-справочник терминов нормативно-технической документации

  • архитектура системы контроля и управления — 3.36 архитектура системы контроля и управления (l C system architecture): Организованная структура системы контроля и управления. Примечание См. также «архитектура контроля и управления». Источник: ГОСТ Р МЭК 61513 2011: Атомные станции. Системы… …   Словарь-справочник терминов нормативно-технической документации

  • Система контроля и управления — 4 Система контроля и управления Реализована на любых технических средствах Источник: РД 153 34.1 04.504 01: Тип …   Словарь-справочник терминов нормативно-технической документации

  • категория функции контроля и управления — 3.4 категория функции контроля и управления (category of an l C function): Одно из трех возможных обозначений (А, В, С) функций контроля и управления, устанавливаемое в результате рассмотрения влияния выполняемой функции на безопасность. Если… …   Словарь-справочник терминов нормативно-технической документации

  • полный жизненный цикл безопасности контроля и управления — 3.39 полный жизненный цикл безопасности контроля и управления (overall safety life cycle of the l C): Необходимый объем действий, включающий в себя оснащение всей архитектуры контроля и управления системами и оборудованием, важными для… …   Словарь-справочник терминов нормативно-технической документации

  • система контроля и управления (СКУ) — 3.35 система контроля и управления (СКУ) (l C system): Система, основанная на применении электрической и/или электронной и/или программируемой электронной техники, выполняющая функции контроля и управления, а также функции обслуживания и… …   Словарь-справочник терминов нормативно-технической документации

  • архитектура контроля и управления — 3.31 архитектура контроля и управления (l C architecture): Организованная структура систем контроля и управления АС, которые являются важными для безопасности. Примечание 1 См. также «структура системы контроля и управления», «система контроля и… …   Словарь-справочник терминов нормативно-технической документации

  • функция контроля и управления — 3.32 функция контроля и управления (l C function): Функция контроля, управления и/или наблюдения за определенной частью процесса. Примечание 1 См. также «подфункции контроля и управления», «функции контроля и управления и соответствующие системы… …   Словарь-справочник терминов нормативно-технической документации


Поделиться ссылкой на выделенное

Прямая ссылка:
Нажмите правой клавишей мыши и выберите «Копировать ссылку»

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.